Devices such as firewalls, server load balancers, and deep packet inspection devices intercept application traffic travelling over TCP connections and may forward them after some level of processing. Other devices operate as end points for TCP connections and may serve the application level requests received over those connections. For both types of devices, one measurement of performance is the rate at which they can process bytes coming from both directions (client and server) without any errors.
In order to measure this rate, a tool is needed which can initiate data from a client and receive data from server at a certain configured rate. An ideal approach could be to divide the configured rate among client and server and let each side generate data based the unidirectional rate calculated for that respective side. This approach has the disadvantage, however, that both sides must be controlled. For example, in a simple network in which a piece of test equipment communicates with a device under test (DUT), the tester can directly control how much traffic it transmits to the DUT but is not likely to be able to directly control how much traffic the DUT transmits to the tester. Even if the DUT can be directly controlled by the tester, this approach works well only if both sides can generate data independent of each other.
For most ISO Layer 7 protocols, however, that is not the case. Most of the Layer 7 protocols are request/response based and hence the initiation rate of one side may be dependent upon the initiation rate of the other side. For example, the initiation rate of a server that provides responses to requests that are generated by a client is dependent upon the initiation rate of the requests. In a request/response protocol, the response rate is driven by the request rate; there is no mechanism by which the response rate can be controlled independently of the request rate. Even if the protocol did have such a mechanism, where the client and server are running on two different systems with timers that are not in sync with each other, it is difficult if not impossible to provide the coordination and control necessary to implement the ideal approach described above.
As a result of these limitations, a conventional approach is to attempt to control the bi-directional data rate from one end, e.g., via the client in a client-server arrangement. Although the client can directly control the rate of data transmitted, such as controlling the number of requests that are issued, and thus indirectly control the number of responses that the client can be expected to receive, the client cannot directly control the rate of data received. For example, a client has no direct control over a server's transmitted data rate. The same difficulty applies regardless of which end is being controlled. For example, when the server side is being controlled, the server's transmitted rate may be controlled but the server's received data rate, i.e., the clients transmitted data rate, cannot be controlled from the server side alone. Even when there is indirect control of the other party's data rate, such as where a request-response protocol is being used, conventional systems don't control the receive rate independently of the transmit rate.
Accordingly, in light of these difficulties associated with conventional solutions, there exists a need for methods, systems, and computer readable media for controlling both transmit and receive throughput over a TCP connection. Even more desirable is the ability to control both Tx and Rx throughput via a device that is either at one end of the connection or that intercepts traffic between the two ends of the connection.